home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13192 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB

  1. Path: inforamp.net!ts32-15
  2. From: rmorin@inforamp.net (Randy Charles Morin)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: Sun, 24 Mar 96 04:40:42 GMT
  6. Organization: MiddleWorld SoftWare
  7. Message-ID: <4j2jot$svj@sam.inforamp.net>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net> <4isu2t$opo@janus.pec.co.nz>
  9. NNTP-Posting-Host: ts32-15.tor.inforamp.net
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. In article <4isu2t$opo@janus.pec.co.nz>,
  13.    JohnM@hypatia.pec.co.nz (John Marshall) wrote:
  14. >I think you have a hard time convincing anybody of this because it's
  15. >not true.  It seems to me that "data hiding" has to do with the actual
  16. >*text* of clients' source code, and that recompilation is merely an
  17. >implementation detail.
  18. >If we had really defeated the purpose of data hiding, the statement
  19. >would be: "if your data's type changes, then you have to rewrite all the
  20. >clients".  This is not the case when accessors are functions which just
  21. >happen to be inline.
  22. >Of course, in practice, all that recompilation during development is a
  23. >major pain.  I guess that's why people put what are going to be inline
  24. >accessors in library.inc, and include library.inc in either library.cpp
  25. >or (for inlining) library.hpp, dependant on whether it's a "dev make" or
  26. >"production make" respectively.  Certainly they're implementation -- they
  27. >don't *belong* directly in the header file.
  28. >Seems to me that the fundamental problem is that include files are
  29. >inherently broken compared to more automatic ways of managing the required
  30. >information.  Alas.
  31.  
  32. Great, so your code is object oriented, encapsulated and has data hiding.  But 
  33. your post compilation objects are not encapsulated and don't use data hiding. 
  34.  That means, that if your object data member's changes types, then you have to 
  35. make an effort to conform other objects to your changes.  If you don't have 
  36. inline accessors, then you don't have a problem.  Is this so hard to 
  37. understand?
  38.  
  39. Imagine you are a producing a commercial system for several large 
  40. corporations.  The large corporation use your hooks (sometimes inline 
  41. accessors) to add functionality that is dependant on their particular business 
  42. needs.  After shipping version 1.0 with an object of type char (inline 
  43. accessed), you ship the less buggy version 1.1 with the data type changed to 
  44. an int.  Now you have to coordinate your releases with the corporations.  If 
  45. you eliminate inline accessors, then you don't have that problem.
  46.  
  47. When you talk about having to rewrite code because you defeated data hiding, 
  48. you are limiting your scope to the problems encountered by a small development 
  49. environment.  This is not usually a problem when you are the only developer 
  50. and you don't share code, but when you are sharing code with 100s of 
  51. co-developers, you can't expect everybody to coordinate the changing of a data 
  52. type.  I hope I've convinced another.
  53.  
  54.  
  55. Agrivar
  56.  
  57. aka     Randy Charles Morin
  58.     MiddleWorld SoftWare
  59.     Canada: 1-800-363-3780
  60.     Other:    905-279-2087
  61.